Refactors the container logic out of the simulator VM file so it can be
used for both VM and host container backings.

The following file structure is now in place:
* container.go - wraps docker operation execs
* container_virtual_machine.go - orchestration of containers for VMs
* container_host_system.go - orchestration of containers for Hosts
* container_xxx_test.go - test for container backed VMs/Hosts

Add CGO_ENABLED=1 to test command with -race

This adds support for backing a host with a container in a similar
manner to how we back VMs with containers.

Hosts do not have the VM ExtraConfig mechanism, and "creation" of a
host is more "register the existance of" vs VMs that are actively
constructed from the provided spec. As such, this uses the advanced
options mechanism provided by the per-host Option Manager instead
of ExtraConfig, but following the same "RUN.container" key/value
approach for defining a container backing.

The created container for a host has the following volumes defined:
* bootbank (read-only)
* altbootbank (read-only)
* OS-DATA (read-write)
* datastore1 (read-write)

The volumes have suitably formed UUIDs, are mounted under
/vmfs/volumes, and have symlinked pretty names.

The volumes are associated with the host via labels, allowing the
use of filtered queries to retrieve volumes associated with a given
host.

All docker invocation is kept in container.go and out of the
container_xxx.go files. Not clear this is a fundamental benefit, but
should make it easier if we ever want to support remote docker hosts.

Creates an OptionManager instance per-host, with valued seeded from the
ESX template but not directly referencing it, ie. template changes will
not reflect into existing OptionManager instances.
OptionManager Query and Update methods work as expected.

Changes made via OptionManager are reflected into host.Config.Options
array, but it's a unidirectional reflection. This is done to match
infered behaviour of ESX.

There are two OptionManager instances for ESX (and I assume for VC),
For ESX they are found at:
* ServiceContent.setting
* ConfigManager.advancedOptions

The settings for ESX are empty, and the template had named the adv
opts as settings. This adds an empty Setting array in the templates to
clearly differentiate which set of BaseOptionValues is used to populate
which OptionManager instance.

Follow up required for:
* VC to determine what the contents of adv opts should be.
* whether HostConfigInfo.Options is adv opts, or combined set

Connects sim-hosts to bridges as specified in their config.
The bridges to use for a given pNIC are expressed in the advanced
options using the following pattern (example for pNIC 0):
	RUN.underlay.vmnic0=vcsim-mgmt-underlay

This uses an existing bridge or creates a new one as
needed.

If a host has a container backing, all pNICs defined in the host
template are discarded and new pNICs are created, 1 per underlay
name provided to simulator.HostSystem.configureContainerBacking.
This was the only sane way I found to indicate which bridges a
host should be connected to.

The IP assigned to the container is reflected into the various
host.Config structures associated with the vmknic, eg.
VirtualNicManagerInfo

The simulator.HostSystem.getNetConfigInterface method is prvoided to
allow a caller to retrieve all the various network entities associated
with a NetConfig binding, eg. "management", "vmotion".

Remove use of errors.Join to maintain support for older Go versions.

Known issues:
* podman volume ls filters act as OR instead of AND which results in
  all volumes being deleted any time a single host is removed. Issue
  opened and fixed in podman main.

If "RUN.container" is added or removed on an existing VM, that change
is applied immediately if the VM is currently powered on.

Modifications to the value of the key do not have an effect unless the
continue needs to be recreated for some reason.

Switches to Go templates for formating docker command output

Includes additional error logging detail

Makes use of the docker events stream to trigger inspect operations
against containers where waiting for things such as IPs.

Corrects prior failure to stop the async container watch when the
container was removed.

Updates to locking to avoid race warnings.

Updates vcsim.bats to look for a volume with `--dmi` suffix instead
of a volume with the plain container name.

Adds a stage to the github actions pipeline that provides an ssh server
that allows interactive login to the environment. This only triggers on
failure.

The reason for adding this is due to repeated failures to find
functional arguements for the specific docker version present. Quirks
around the format parameter values specifically.

This is done using the tmate action:
https://github.com/mxschmitt/action-tmate

Corrects boilerplate

I expect to squash this into an earlier commit once it passes tests
vcsim: support container backing for hosts